home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / STUTTGART / LANG / C / LIB / LIBGPP / LIBSTDC / !libstdc / stl / ReadMe
Text File  |  1996-06-18  |  4KB  |  87 lines
  1. This directory contains Hewlett-Packard's implementation of
  2. the C++ Standard Template Library.
  3. It is the October 31, 1995 version.
  4. It has been extensively modified so it can be compiled by g++.
  5. (Version 2.6.1 or newer is recommended.)
  6. Some of these hacks are pretty ugly, but are needed to work around
  7. bugs in g++ (which we are working on).
  8. Thanks to Carsten Bormann <cabo@informatik.uni-bremen.de> for
  9. coming up with many of these work-arounds.  However, I have
  10. come up with alternate (possibly inferior!) work-arounds in some cases.
  11.  
  12. Note that this is based on a pre-Draft Standard for C++.
  13. Things are likely to change.  For example, the header file names
  14. are very likely to change.  The Allocator interface will change.  Etc, etc.
  15. CYGNUS MAKES NO COMMITTMENT (yet) TO SUPPORT BACKWARD COMPATIBILITY FOR STL.
  16.  
  17. For examples if things that should work, look in the ../tests directory.
  18.  
  19. DOCUMENTATION:
  20. See http://www.cs.rpi.edu/~musser/stl.html on the World-Wide Web,
  21. or anonymous ftp to butler.hpl.hp.com, directory stl, file sharfile.Z.
  22.  
  23.     --Per Bothner
  24. Cygnus Support     bothner@cygnus.com
  25.     
  26. -----------
  27. Here is Carsten Bormann's notes on his changes:
  28.  
  29. This is a set of seriously bletcherous hacks to HP's wonderful STL
  30. library.  The objective is to hammer STL through GCC 2.6.1 (2.6.0
  31. seems to work, too, until you run into one of its bugs) so that us
  32. academic types can play with STL, not to make STL better in any way.
  33.  
  34. Many of these changes make the library much less efficient.  All
  35. changes (except vector<bool> -- see below) are due to bugs (or
  36. non-features) in GCC, not due to any problems in STL.  Do not judge
  37. the performance of STL (code space, data space, compile time
  38. complexity, run time complexity) from these hacks -- they will be much
  39. better when GCC implements more of Standard C++.  May the authors of
  40. STL forgive me.
  41.  
  42. The class templates generally have been hacked in the following ways:
  43.  
  44. 1) Static data members have been eliminated, generally by making them
  45. non-static members or member functions (both of which generally
  46. seriously impairs performance -- e.g., each rb_tree iterator now
  47. carries a copy of NIL since there is no other place to put it).  The
  48. template list<> has suffered most.
  49.  
  50. Allocators are still static members, since I changed defalloc.h to
  51. have static members only.  (This makes allocators less useful, but
  52. still useable.)  (Note that a static member without data need not be
  53. initialized.)
  54.  
  55. 2) For member functions defined outside the class template, parameters
  56. of type tmpl<T>::something have been changed.  In some cases, a class
  57. derived from the type has been used; in some cases the function simply
  58. has been made inline (again causing code bloat).
  59.  
  60. 3) A number of function templates in iterator.h have been declared
  61. again for derived classes defined by templates, usually by making them
  62. friend functions and using the name injection feature of GCC.  I don't
  63. understand the relevant sections of the WP, so I don't know if this
  64. hack will cease to work in more conforming versions of GCC or become
  65. unneccessary or simply STL won't work with standard C++.  Some of
  66. the necessary friends may still be missing...
  67.  
  68. defalloc.h has lost much of its functionality: see above.
  69.  
  70. bool.h has been made ineffective, since GCC supports bool.
  71.  
  72. Finally, bit_vector has been changed into a proper specialization of
  73. vector<bool>.
  74. [Not in this libstdc++ release. -PB]
  75.  
  76. demo.cc and Makefile build a small demo program for a number of
  77. features of STL.  This is not a test suite, so I certainly have not
  78. found all my mistakes (could anyone in possession of such a test suite
  79. please run it over these hacks?).  Send bug reports (that follow GNU
  80. bug reporting conventions) to
  81.  
  82.     cabo@informatik.uni-bremen.de
  83.  
  84. Note that I generally do not have time to answer questions about STL.
  85.  
  86. Carsten Bormann
  87.